To all who have responded directly to me regarding this topic, I apologize for not returning your email. I wanted to verify a few things first, before commenting. Now, I am fairly certain that what I found is correct: After playing with the sample program, I RTFM. Actually, I RTFM before this to see what the *utxline() functions did. This time, I actually read every word! In the man page for getutxent(3C) I found: file. It returns a pointer to the utmpx structure. When called by a non-root user, pututxline() invokes a setuid() root program to verify and write the entry, since /etc/utmpx is normally writable only by root. In this event, the ut_name field must correspond to the actual user name asso- ciated with the process; the ut_type field must be either USER_PROCESS or DEAD_PROCESS; and the ut_line field must be a device special file and be writable by the user. Which program? On my box, it seems to be a pretty good secret. But being curious, I had to find out! I dynamically loaded the binary to see if running strings(1) on it would tell me. No luck. Then I used abort(3C) after the pututxline call to find a file name. That worked! It seems that when a user tries to do the update, the following program is run: -r-sr-xr-x 1 root bin 5996 Jul 16 1994 /usr/lib/utmp_update This is from a Solaris 2.4 on a pee cee. On my system, utmp_update will only allow me (the user) to update the ut_type field. It wouldn't let me update the ut_line field. I even put in "real" line names (look at your /dev directory and the 1001 symbolic links, Sun seems to have gone bananas with symbolic links again!). I called a friend at Sun in Mt. View. He confirmed this for me and that it is not a bug, but a feature!! :-) Then I asked some questions. I am going to paraphrase my questions and his answers (he asked to remain anonymous)--mainly because I don't take short-hand! I believe they are fairly accurate. Key: Me: Scott Barman (me!) SE: My friend the software engineer at Sun. Me: Why is this a "feature?" SE: For all the 1001 things that init now does, it doesn't "log out" a user when the user hangs up. The shells have all been hacked to catch all the signals and if they are going to exit, to update the utmp and utmpx files before they go. The init under SunOS did write logout messages to utmp when the process attached to the tty exited. Me: Is it possible for a user to make it look like he/she was not logged in? SE: No. Not unless someone hacked init. It generates a login message for all connections, including ftp. Actually, it's login and ftpd that make those entries, not init. Me: What about security? Isn't this dangerous not knowing who is on the system? SE: Do you enforce the use of the "-ls" option with xterm? (The -ls starts a login shell to the window) Or do you run shelltool and command tool? How easy is it to run an rsh to start an xterm to get displayed on another system? I do it all the time, and my "login" information does not appear in the wtmp file. If these do not create umtp entries to begin with and you run them, why should this be a problem? Me: The way the manual reads I can change the ut_line field but my test program cannot. Why? SE: The man page says that? The man page is wrong! The wtmp_update program uses the user name and the line value to find the proper record for the user. If you do not pass the correct values, the wtmp_udate program will not do the update. Me: Is there anyway to make it look like someone is still logged in when they are not? SE: Haven't you seen this on SunOS? Xterms do this all the time!! (I have and they do) I don't think this is a security problem. Me: Some people have suggested this is a security hole. What do you say? SE: It's more of a pain in the behind than anything else. We've had customers call up and complain because they were relying on init to record the "logout" of their custom app, one that is started like a login shell (after login runs). But that's System V. We have to be SV compliant, so we do what the specs say and this is how the sources came to us. The rest of the conversation was "personal" in nature (he's an old friend! :-). However, he did convince me it wasn't as bad as it looks and is really not something to worry about. Then again he and I also agreed that the System V init was too bloated, did too much and we both couldn't find that much of an advantage in it over the old init in SunOS. I hope that answers the questions on this subject. scott barman scott@disclosure.com DISCLAIMER: I speak to anyone who will listen to me and I speak only for myself!